collection

2.4. Timezones

Though not directly linked to recurrences, the timezone is one of most difficult part to implement and least useful for majority of users. Many users just use one timezone.

The big piece of hard functionality from 2445 that vendor hasn’t implemented is timezones.

Standard C library APIs deal well with only two timezones: UTC, and the local timezone (whatever that is). So, vendor’s library works well in these two cases, including with RRULEs that cross DST shifts. Vendor needs to implement a date-time abstraction that uses timezones as specified by VTIMEZONE. Vendor Vendor hasn’t had the time yet. Suspects that the widespread lack of good APIs to deal with timezones will be the biggest interop headache for many implementations. But, vendor feels that we can’t take timezones out of the spec, they are critical to how time is measured/used, and we need a protocol that will work properly between CUAs in various timezones. This is hard, but necessary.

Vendor confused by 4.6.5.c and posted two possible answers:

  1. We never export invalid time zone information, and we never reference undeclared time zones.

  2. A recurring appointment which gets shifted by a time zone (e.g. Daily from 1pm to 2pm PST) can have an exception which is all day long (floating).